
Enterprise Network Management 
Part II: SNA Peer-to-Peer 


This is the second of a two-article series on enterprise network management begun in 
the last issue of SNA Perspective. The previous article focused upon subarea SNA 
network management issues, provisions, directions, and implications. 

This article focuses on five aspects of network management in distributed processing 
environments: client/server, APPN, IBM’s LAN Network Manager, standards for 
LAN management, and OSF DME. We also look at the implications of IBM’s 
January announcement of NetView/6000. 

In part I, we noted that networked computing resources are the most valuable and yet 
the least well managed resources in today’s enterprise. We then discussed various 
characteristics of NetView and subarea SNA network managment. System View and 
NetView are IBM’s basis for integrated system and network management in complex 
interconnected environments. System View is a framework for integrated system and 
network management solutions for SNA, Open Systems Interconnection (OSI), and 
Transmission Control Protocol/Intemet Protocol (TCP/IP) applications and their 
associated networks, and is integral to Systems Application Architecture (SAA). NetView 
is IBM’s flagship system and network management product set and provides host- 
based, centralized network orchestration. NetView today works well in SNA subarea 
networks and reflects IBM’s classical host-centric approach to SNA. In this article, 
we will focus on the network management requirements in distributed environments. 

(continued on page 2) 


3174 Part II: Hard Hit by Gateways 

The challenges to the 3174 today are many. The first challenge was the introduction 
of the IBM PC ten years ago. These PCs were eventually enhanced to include 
sophisticated communication programs and sufficient PC horsepower to run the 
programs well at an affordable price. In addition came the proliferation of LANs and 
the emergence of client/server computing. 

This article describes the current and anticipated functionality of the 3174 and SNA 
LAN gateways. We describe the changing environment the 3174 is facing and 
propose several possible changes ahead for the 3174. 

(continued on page 10) 
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Client/server Computing 

The proliferation of price/performance-efficient 
workstations throughout the enterprise has given rise 
to workgroups that share computing resources such 
as applications, information, devices, and services. 
Resource sharing is often provided through LAN 
solutions. Client/server computing provides the 
means for a programmable workstation (PWS) to 
share resources both within the workgroup and 
throughout the enterprise. 

Transparent resource sharing proceeds through the 
interaction of requesting clients and supplying 
servers. IBM’s client/server computing direction 
generally positions client (requester) programs at the 
PWS and server (service-providing) programs at 
enterprise and departmental processors. 

Services accessible by clients include: 

« Backup/archive of workgroup and workstation 
data 

• LAN system problem determination and 
management 

« Software distribution and control 

• LAN system user administration 

• LAN system performance analysis 

• User access control and security management 

• Configuration and asset management 

• Print services 

• Distributed database 

• Distributed files 

• Distributed office functions 

• Computer-integrated manufacturing (CIM) 

• Distributed object integration 

• Distributed processing 


Three elements are necessary to meet user needs for 
a client/server interface: 

• A consistent access procedure. Users require 
access to the above services in a consistent way, 
regardless of target application location or 
processing environment. 

• A window interface. Users prefer windows 
and/or icons rather than a command line-based 
interface. 

• A consistent look and feel. Users want a 
consistent way to interact with a wide range of 
applications mnning in a wider range of local 
and remote workstation, midrange, and host 
platforms. 

Heterogeneity Hampers Network 
Management 

Target application platforms often reside in local as 
well as remote processing environments. These 
environments are usually heterogeneous and abound 
in inteiprogram and network incompatibilities. To 
exacerbate matters, the wide array of routing and 
bridge products themselves provide solutions to 
these problems in an inconsistent way. The inevita¬ 
ble result has been the emergence of incompatible 
networked application environments that do not lend 
themselves to efficient or effective connectivity, or 
even consistent or reliable network management. 

Client/Server Management Requirements 

Network management requirements in a client/server 
workgroup and between this environment and 
enterprise processors should: 

• Be vendor-independent 

• Cover LAN, LAN-to-LAN directly, and LAN- 
to-LAN across WANs 

• Manage heterogeneous environments 

• Provide the following features: 

Problem management. Manage network 
problems (unwanted changes) from their 
detection through to final resolution. This 
includes disciplines such as problem determina¬ 
tion, problem diagnosis, problem bypass and 
recovery, problem resolution, and problem 
tracking and control. 
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Performance and accounting management. 
Quantify, measure, report, and control the 
responsiveness, availability, utilization, and 
usage charges of network components. 

Configuration management. Control 
information that is necessary to identify physical 
and logical networked resources and their 
interrelationships. 

Change management. Plan and control the 
additions, deletions, and modifications of 
networked hardware, software, and microcode 
resources. 

Security management Prevent unauthorized 
access to protected resources, authenticate peer 
entity and data origins, provide access control, 
provide for traffic flow confidentiality and 
integrity in connection-oriented and connection¬ 
less environments, provide selective field 
confidentiality, and ensure nonrepudiation 
throughout. 

Each of the above requirements is a tall order to fill 
just in a straightforward subarea SNA netwoik, let 
alone in a hybrid subarea/APPN netwoik or a 
multivendor network using a combination of SNA, 
OSI, and TCP/IP. 


APPN Network Management 

Advanced peer-to-peer networking (APPN) SNA 
provides the basis for dynamic connections between 
distributed applications. Subarea SNA, on the other 
hand, is the classical SNA method whereby 
nonprogrammable terminals (NPTs) access host- 
resident applications. In subarea networks, the host 
applications control access and configurations. 
Application invocations and routing logic are 
predefined and must be manually redefined. 

APPN is architected on the basis of Node Type 2.1 
(NT2.1). APPN network node servers provide the 
basis for dynamic determination of remote 
application location, as well as dynamic calculation 
of end-to-end routing and intermediate node routing. 


APPN Is Strategic... 

IBM has introduced APPN for several of its major 
platforms: System/36 (1986), AS/400 (1988), 
ES/9000 under DPPX/370 (1990), 3174 establish¬ 
ment controller (1991), PS/2 with Netwoik 
Services/2 (NS/2) (under OS/2 EE) (1991), OS/2 
Version 2 Communication Manager (1991). 

These successive implementations of APPN make it 
clear that IBM is committed to peer-to-peer 
networking across the entire range of its major SAA 
enterprise, departmental, and workstation platforms. 
In January 1992, IBM announced that it would 
license APPN network node to other vendors, to 
further increase its availability on a wide range of 
platforms. 

It also appears inevitable that APPN netwoik node 
will be provided on the RS/6000, which is IBM’s 
principal Advanced Interactive Executive (AIX) 
platform. SNA Perspective believes that APPN will 
be supported on the RS/6000 because IBM has 
increasingly positioned the SAA and AIX platforms 
as interoperable. Furthermore, IBM announced last 
month that APPN will be supported on its new multi¬ 
protocol router, the 6611 (see IBM Announcements 
in this issue), which is based on an RS/6000 engine. 

Clearly, APPN is IBM’s SNA routing solution for 
distributed workgroup, client/server users. APPN 
functions as a peer SNA routing protocol set that can 
conceptually select from a range of possible 
underlying WAN and LAN data links transparently. 
APPN is potentially suitable for providing dynamic 
SNA peer connections over data link environments 
including but not limited to: 

• Token ring 

• Ethernet and IEEE 802.3 Carrier-Sense Multiple 
Access/Collision Detection (CSMA/CD) 

• IEEE 802.4 Token-Passing Bus 

• Synchronous Data Link Control (SDLC) 

• High-Level Data Link Control (HDLC) 
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APPN is an evolving routing protocol set which is 
quite likely to include support for higher speed link 
environments to include: 

• Fiber Distributed Data Interface (FDDI) 

• IEEE 802.6 Metropolitan Area Network 

• Integrated Services Digital Network (ISDN) 

• Broadband ISDN 

• ES/9000 Enterprise System CONnection 
(ESCON) optical fiber channel 

• Gigabit LANs 

• Synchronous Optical NETwork (SONET) 

...But NetVIew Can’t See It 

Users and their increasingly distributed applications 
require the dynamic, peer-to-peer capabilities of 
APPN in concert with higher speed connections. A • 
significant network management concern here is 
that, at present, host-resident NetView is not able to 
maintain awareness of a downstream dynamic 
network environment That is, NetView network 
awareness is generated and maintained by static 
updates to its tables. Downstream fluctuations in the 
network due to the inherent APPN network node 
functions of dynamic directory, dynamic route 
selection and intermediate node route calculations, 
are simply not known to NetView on an ad hoc 
basis. It seems to SNA Perspective to be quite 
inconsistent to provide APPN network node 
functionality across the entire SAA platform set and 
yet not provide a commensurate capability to 
manage this dynamic environment. 

What NetView Needs To Support APPN 

Each of the following desirable capabilities are 
discussed in more detail below: 

• NetView should intercept APPN topology 
changes automatically 

• APPN management should include dynamic 
change management and dynamic performance 
and accounting management 

• Configuration management in APPN should 
extend beyond boundary node 


• APPN management should include dynamic 
automated operations, dynamic security 
management, and consistent implementations 

• NetView should enable multitier APPN problem 
management disciplines 

• SAA and AIX environments should consistently 
apply APPN-cognizant focal point, entry point, 
and service point logic 

SNA Perspective believes that NetView and its 
supporting products should be able to intercept and 
record APPN network topology changes as they 
occur without operator intervention. Peihaps the 
mechanism to accomplish this would be to provide 
the capability for any APPN network node topology 
data unit (TDU) exchange resulting in network node 
local, cache, or network directory rewrites to update 
a NetView topology database. That is, one solution 
would be to architect a Management Services (MS) 
TDU capability wherein NetView or any other focal 
point, entry point or service point implementation 
could issue and capture MS TDUs generated by 
APPN network nodes and, in so doing, dynamically 
update its view of an entire APPN network. (Entry 
point, service point, and focal point are defined in 
part I of this series in the January issue.) 

SNA Perspective believes that NetView and any 
other focal point products, as well as entry point 
products, should support a dynamic network 
management topology view at global, network node, 
end node, low-entry networking node, link 
characteristic (active, inactive, bandwidth), session, 
and conversation levels. 

Furthermore, SNA Perspective believes that 
configuration management capabilities in an APPN 
managed environment should extend well beyond 
the boundary node (from the NetView perspective) 
level. Since user experience with token ring 
implementations suggests that source routing (the 
token ring bridge scheme) is reasonable through six 
bridges, perhaps six embedded topological tiers of 
view should be provided in a dynamic NetView/ 
APPN environment. SNA Perspective thinks that 
NetView and supporting products should enable 
multitier APPN problem management disciplines 
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including problem determination, problem diagnosis, 
problem bypass and recovery, problem resolution, 
and problem tracking and control. 

This APPN network management environment 
should also include the following features: 

• Dynamic change management which enables 
awareness of additions, deletions, and 
modifications of networked hardware, software, 
and microcode resources on an ad hoc basis 
without the need for manual table updates. 

• Dynamic performance and accounting 
management which incorporates awareness of 
the results of quantifying, measuring, reporting, 
and controlling the responsiveness, availability, 
utilization, and usage charges of network 
components into the network routing and session 
recovery decision process. 

• Dynamic automated operations which would 
extend the current expert systems and automated 
management capabilities to include dynamic 
updating of knowledge-based, rule-based, 
inference engine tables as a function of topology 
changes in network node and associated 
resources. 

• Dynamic security management. 

• Consistent SAA and AIX implementations. 
APPN is integral to SAA and, as stated earlier, 
SNA Perspective believes that IBM will 
incorporate APPN capabilities into AIX. 

The Net View interface on the enterprise processors 
is currently through Multiple Virtual Storage 
Subsystem Interface (MVS SSI), Virtual Machine 
Programmable Operator (VM PROP), and Virtual 
Storage Extended Operator Communications Control 
Facility (VSE OCCF). These and the other SAA 
runtime environments (OS/400 and OS/2) as well as 
the AIX runtime environments (ESA/AIX, 
AIX/6000, AIX PS/2) should consistently apply 
APPN-cognizant focal point, entry point, and service 
point logic. Perhaps LAN-resident APPN network 
node servers could function as local service points 
and present themselves upstream to APPN-cognizant 
NetView hosts as satellite focal points. 


LAN Management 

This section looks at IBM’s LAN Network Manager 
and Heterogenous LAN Management (HLM). 

LAN Network Manager 

IBM announced LAN Network Manager Versions 
1.0 and 1.1 as well as LAN Network Manager Entry 
in September 1990. There have been phased ship¬ 
ments of LAN Network Manager Version 1.0 since 
April 1991, but general availability will be in the 
latter part of March 1992. LAN Network Manager 
Version 1.1 and LAN Network Manager Entry are 
planned for availability in mid-December 1992. 


These LAN Network Manager programs run under 
OS/2 EE and OS/2 Version 2. They enable 
management of multisegment IBM token ring and 
broadband/baseband IBM PC Networks as well as 
the IBM 8209 LAN Bridge that interconnects token 
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ring and Ethernet LAN segments. This environment 
is characterized in Figure 1 (see page 5). LAN 
Network Manager enables management of a LAN 
either centrally from a Net View host or locally 
through the operator interface at the LAN 
workstation. The operator interface is based on the 
SAA window-based presentation interface using 
OS/2 Presentation Manager. The OS/2 Database 
Manager provides a Structured Query Language 
(SQL)-based relational database environment within 
which to construct a LAN configuration database. 

LAN Network Manager extends Net View LAN 
commands to support access to a set of LAN 
functions from Net View Version 2 Release 2 and 
onward. This begins to provide the basis for an 
enterprise-wide. Net View-orchestrated LAN/WAN 
management solution. LAN Network Manager 
Entry, in concert with NetView Version 2 Release 2 
and onward, enable management of remote, single¬ 
segment token ring or broadband/baseband PC 
Networks. There is no user interface at the LAN 
Network Manager Entry station. These LAN 
network management products, while beginning to 
address LAN/WAN SNA network management, do 
not provide support for multiprotocol (SNA, OS I, 
TCP/IP) environments. 

In June 1991, IBM introduced AIX NetView Service 
Point, which generates a gateway to NetView for 
management systems running on Unix platforms. 
The AIX NetView Service Point arrangement is 
shown in Figure 2. AIX NetView Service Point is 
supported on the RS/6000 POWERserver and 



POWERstation as well as on the SUN UNIX 
SPARCserver and SPARCstation. This UNIX 
platform for service point logic generates network 
management vector transport (NMVT) request units 
(RUs) from TCP/IP SNMP flows. In January 1992, 
IBM introduced Net View/6000, which is essentially 
an SNMP Manager with a user interface and 
communication to NetView (see Announcements 
section in this issue for more details). 

These LAN/WAN network management approaches 
certainly fill specific niches. However, they do not 
provide the level of overall network management 
level of openness required by users increasingly 
operating in multivendor, multiprotocol environ¬ 
ments. SNA Perspective believes that it will become 
increasingly important for IBM to provide 
transparent network management support for 
integrated SNA, OSI and TCP/IP networked 
applications. In September 1990, IBM formally 
expanded its Open Network Management (ONM) 
direction to encompass open, end-to-end 
management of heterogeneous networks. 


NetView Multivendor Platform 


NetView 
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ONM specifically states it will support these mixed 
environments through the use of open management 
architectures for SNA, OSI, and TCP/IP. Figure 3 
(see page 6) summarizes NetView support for SNA, 
OSI, and TCP/IP tasks. 

Figure 4 expands on Figure 3 to include AIX 
NetView Service Point and non-IBM network 
management systems. Significantly, Figure 4 also 
represents the SNA Perspective viewpoint that 
NetView will be enhanced to support APPN as well 
as LU 6.2. 

Heterogeneous LAN Management 

Enterprise networks are increasingly characterized 
by multiple workgroup LANs interconnected by 
intersubnetwork WANs. Departmental LANs in turn 
support a mixture of media types and operating 
system environments. A typical mixture includes 
the coexistence of token ring and Ethemet/IEEE 
802.3 LANs. Networks in Fortune 1000 corporations, 
government agencies, and universities tend to 
include mixed media LANs. The two major LAN 
management protocols considered for use in 
heterogeneous LAN environments are OSI Common 
Management Information Protocol (CMIP) (defined 
by the International Standards Organization (ISO)) 
and the Simple Network Management Protocol 


Open Network Management Approach 



(SNMP) (defined by the Internet Engineering Task 
Force (IETF)). 

Enterprise networks are increasingly multivendor in 
nature. These also employ varying combinations of 
SNA, OSI and TCP/IP application and networking 
approaches. Bridge, router, and gateway solutions 
proliferate from an increasing number of vendors. 
These solutions themselves provide for heteroge¬ 
neous networked application solutions in an 
inconsistent way. The inevitable result has been the 
emergence of incompatible networked application 
environments which do not lend themselves to 
efficient or effective connectivity, let alone 
consistent or reliable network management. 

IBM and 3Com have addressed the problem of 
network management in a mixed LAN environment 
through cooperative development of an approach 
called Heterogeneous LAN Management (HLM). It 
is significant that IBM and 3Com have teamed up in 
this effort, as they are the leading vendors for token 
ring and Ethemet/IEEE 802.3 LAN adapters, 
respectively. Key to development of HLM was the 
issue of managing a LAN environment comprised of 
a mixture of operating system environments (such as 
DOS, OS/2, UNIX, etc.) in addition to addressing 
the problem of network management of a mixed 
media environment. HLM design goals are: 

• To manage all types of end stations (such as 
workstations running DOS, OS/2, UNIX) in 
addition to concentrators, hubs, routers, bridges, 
and servers 

• To provide an architecture to manage Ethernet 
and token ring LANs today with provision for 
additional LAN types tomorrow 

• To provide minimal management services that 
can be supported by any network node, with 
extensions to support vendor and user extended 
management entities 

• To be a standards-based architecture 

• To provide application program interfaces 
(APIs) through which developers can create 
compatible network management software 

• To provide specifications of what management 
data is accessible 
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The HLM base management protocol is specified by 
use of the OSI CMIP standard using a lower level 
logical link control (LLC) network service. The 
result is CMIP over LLC (CMOL). LLC is specified 
by IEEE 802.2 and is a frequently implemented data 
link sublayer. Essentially, LLC defines how 
command packets are generated and interpreted for 
support of logical link functions of one or multiple 
logical links. SNA, OSI, and TCP/IP traffic flows 
are all supported over LLC. 

HLM base services are provided by an entity called 
the LAN Station Manager (LANSM). LANSM 
functions are provided by all HLM stations whether 
they are managing or being managed. These 
functions include: 

• Discovery/registration 

• CMOL processing 

• Base-level Management Information Base 
(MIB) services 

• Extended API support 

CMIP and SNMP 

It is interesting to note that several other vendors are 
pursuing SNMP as their preferred LAN network 
management approach. This is certainly due in part 
to increasing market acceptance of TCP/IP as well as 
to the relative simplicity and lower cost of SNMP as 
compared to CMIP. However, it is also important to 
consider the relative technical benefits of CMIP over 
SNMP (see Table 1). 


Relative Merits of CMIP and SNMP 

CMIP 

SNMP 

Excellent automation potential 

Limited automation capability 

Manager and agent well 
defined 

Manager and agent not well 
defined 

Rich access control 

Agent cannot authenticate 
commands from manager 

Event driven 

Limited event-driven support; 
mostly manager polling 

Rich monitoring and control 

Limited monitoring; 
no scoping or filtering 

Complex 

Simple 

Few current suppliers or 
implementations 

Many suppliers and many 
products on market 

Expensive 

Inexpensive 


Table 1 


Clearly, Table 1 is a very limited comparison of 
CMIP and SNMP. However, SNA Perspective 
believes that IBM will continue to promote support 
of CMIP in the heterogeneous LAN environment 
through the 3Com/IBM HLM architecture and 
throughout the enterprise internetwork environment 
through the SAA System View direction. Nonethe¬ 
less, it is highly likely that IBM will continue to 
support SNMP as well as CMIP on Net View. 


Managing SNA, OSI, and TCP/IP 

Open networking in today’s environment requires 
that users be able to transparently access SNA, OSI, 
or TCP/IP applications in a consistent way. SNA 
remains IBM’s proprietary network architecture and 
has certainly established itself as the predominant 
international de facto networking approach. 

SNA Perspective believes that IBM will continue to 
support both subarea and APPN SNA, but will 
emphasize development of APPN. SNA Perspective 
further believes that APPN will be announced in 
NCP and VTAM by the third quarter of 1992. The 
network management implications of this projected 
capability for NetView are enormous. NetView 
must be significantly and immediately enhanced to 
recognize, process, and reconfigure its knowledge of 
the network on the basis of multiple APPN network 
nodes. Therefore, SNA Perspective believes that 
NetView will also be announced with APPN 
network node TDU processing and directory update 
capabilities during the third quarter of 1992. 

IBM has also emerged in the past three years as a 
leader in development of consistent OSI networked 
applications running in SAA and AIX processing 
environments. SNA Perspective believes that IBM 
will integrate common APIs from programs into 
SNA and OSI services (see “SNA Directions: 1992 
and Beyond” SNA Perspective December 1991). 

This projected integration will certainly require 
consistent and significant evolution of the network 
management product set including NetView, 

Net View/PC, LAN Network Manager, LAN Station 
Manager, the AS/400, and the RS/6000. 
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IBM has classically regarded OSI and TCP/IP as its 
strategic and tactical multivendor approaches, 
respectively. All of IBM’s significant SA A and AIX 
platforms now support SNA, OSI, and TCP/IP. The 
introduction of the AIX Net View Service Point 
underscores IBM’s commitment to providing a 
reasonable degree of network management 
transparency in these three environments. 


IBM and the OSF DME 

The greatest challenge in network management 
today is the lack of consistency in multiprotocol 
networks. Heterogeneous interconnection products 
(bridges, routers, and gateways) provide solutions to 
this lack of consistency, but they are themselves 
inconsistent with other interconnection product 
solutions. Further, major vendors are pursuing 
dissimilar “standard” approaches to network 
management in mixed environments. 

Within the “standards” environment for network 
management, it is important to consider the activities 
of the Open Software Foundation (OSF). Perhaps 
the greatest OSF asset is that it is a collection of 
major vendors who, as a group, are developing a 
standard set of solutions collectively called the 
Distributed Computing Environment (DCE) and 
Distributed Management Environment (DME). 

These solution sets were developed through 
competitive bids in a request for technology (RFT) 
process. The OSF members then develop vendor- 
and protocol-independent products which conform 
to these environments. 

The OSF view is that a DME should enable a 
heterogeneous networked computing environment to 
be managed in a unifonn and efficient manner 
through a consistent user interface. The result 
should be that users would spend less time and effort 
managing their interconnected systems and focus 
more on their applications and work at hand. 

The driving objective of the DME development 
process has been to identify a common framework 
for managing heterogeneous networked application 


environments. This framework defines APIs which 
are accessible by applications in order to invoke 
common management services, store/retrieve 
management information and exchange such 
information with managed objects located in local 
and remote processing environments. The DME 
user interface is conceptually defined to enable both 
a graphical and object-oriented interface as well as a 
character cell (nongraphical) interface. 

Management tasks performed by DME management 
applications include: 

• Remote initialization of network nodes 

• Remote configuration of network nodes 

• Interchange and manipulation of computing 
resource representations 

DME computing resource representations are called 
managed objects. DME common management 
services include management communications, 
event management, event logging, and object 
management. These services also provide for 
intersystem interoperability. 

The primary DME technologies were selected in 
September 1991. These are principally based upon 
Hewlett-Packard’s OpenView systems and network 
management products and the object-oriented 
products of Tivoli of Austin, Texas. 

In April 1991, IBM announced that it would license 
portions of HP’s OpenView. This announcement 
was an evolutionary outgrowth of IBM’s and HP’s 
complementary submissions on DME to OSF. 
Specifically, IBM is licensing HP OpenView 
Network Node Manager and HP OpenView Network 
Management Server, which was part of HP’s DME 
submission to OSF. 

HP Network Node Manager is based on SNMP and 
allows a system administrator to configure, trouble¬ 
shoot, and monitor performance of a TCP/IP 
network from a single workstation. HP Network 
Management Server extends the functionality of HP 
Network Node Manager by using APIs based on OSI 
CMIP. 
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IBM has clearly and consistently stated that its 
support of openness is a primary objective. 
Furthermore, IBM has begun to position both SAA 
and AIX to absorb significant components of DCE 
and DME through OSF/1 and its successors. The 
networking and internetworking interconnection and 
management environments have become more 
complex during the past few years for all of the 
reasons stated above. 


Conclusions 

End users and network administrators share a clear 
requirement for a standard, technology-independent 
way in which to use and manage networked 
computing resources. NetView and its predecessor 
host products have traditionally provided reasonable 
levels of SNA network management hierarchically. 
Users, however, increasingly connect and share 
application resources in a distributed fashion. These 
processes occur on enterprise-wide levels in inter- 
LAN and LAN/WAN/LAN internetworked 
environments. The growing realities of networked 
applications require solutions that address not only 
SNA, but also multiprotocol environments based on 
SNA, OSI, and TCP/IP. SNA Perspective believes 
that IBM’s alignment with DCE and DME is critical 
in providing effective and efficient solutions in these 
settings. 

In summary, SNA Perspective expects that the likely 
development pathway from IBM for network 
management in distributed environments will be: 

• Maintenance of NetView and supporting 
products for subarea SNA management 

• Evolution of NetView APPN interoperability to 
address peer-to-peer SNA 

• Continuing evolution of NetView capabilities in 
OSI CMIP and TCP/IP SNMP 

• Incorporation of DME into NetView and its 
supporting SAA and AIX products 

• Evolution of nonhost-resident SAA/AIX DME- 
supporting products ■ 


(continued from page l) 


3270 Terminals on the Decline 

User productivity today usually requires more than a 
terminal and host-based applications can provide. 
Increasingly, traditional users of terminals find that 
they are performing functions that could be better 
performed on a PC. They are also finding that 3270 
emulation provides sufficient, or even better, SNA 
connectivity than they have with a nonprogrammable 
terminal. LAN-based SNA gateways can provide 
that connectivity in addition to other benefits of 
being attached to a LAN. 

Research by Dataquest Inc. shows a dramatic drop in 
new terminal sales over the past few years and finds 
that more PCs than terminals are now connected to 
3174s (see sidebar on page 16). Much new 
establishment controller business has been to replace 
or consolidate existing controllers since newer 
controllers support more users, new features such as 
downstream devices, and new connectivity options 
including token ring, Ethernet, and ESCON. 

Terminals and Standalone Emulators 

IBM acknowledged the PC presence by letting the 
3174 support coax-attached PCs and by the 
development of PC-based 3270 emulation software. 
Since the introduction of the early PC-based 
emulators—including, for example, IRMA in 
November 1982 and PCOX in June 1983—users 
wanting more than just a keyboard and a display 
have been able to transfer files to and from the host 
system and, by way of the same application program 
interface (API) used for file transfer, have been able 
to take advantage of a growing number of micro-to- 
mainframe applications. Emulators have also kept 
pace with terminals with respect to graphics, 
multisession support, windowing, and keystroke 
recording and playback. With some exceptions (e.g., 
the IBM 3276), 3270 terminals have been limited to 
Category A coaxial or twisted-pair connection to a 
controller. Emulators have also exploited remote 
connections (SDLC, BSC, QLLC) and, more 
recently, token ring attachment to a 3174 establish¬ 
ment controller or 3745 communication controller. 

LAN-Based 3270 Gateways 

In 1986, IBM, CXI, DCA, and others introduced 
LAN-based 3270 gateways. They were limited in 


10 


February , 1992 




SNA Perspective 


©CSI 


scope—a total of five sessions when the gateway 
was coaxially connected to a 3274 cluster controller 
and up to 32 sessions for an SDLC or, in some cases, 
BSC connection. The session limitations for SDLC 
connections recognized the performance limitations 
inherent in running the gateway on a 6- or 8-MHz 
PC AT over a NetBIOS-based LAN. The use of 
coprocessors and, ultimately, of much faster PCs 
overcame many of the limitations, allowing 40- 
session multiplexed coaxial and 254-session SDLC 
and token ring gateways. 


Today’s SNA Gateways 

More than a dozen vendors offer SNA 
gateway/client solutions. Each uses a client/server 
architecture in which one PC or dedicated network 
server is designated as the gateway (or communica¬ 
tions server) and contains the physical connection to 
the host. Gateway and/or client platforms include 
DOS, OS/2, UNIX, XENIX, AIX, NetWare 3.11 
and, for the Macintosh, System 7. 

UNIX is much harder to support than the other 
platforms because there are several different UNIX 
implementations on various hardware platforms. 
CLEO and Rabbit Software dominate the small but 
growing market for UNIX-based micro-to- 
mainframe products. Their products provide similar 
functionality to the DOS and OS/2 products. 

SNA gateways support a variety of host connections. 
However, as discussed below, they do not yet cover 
all the options available on 3174 establishment 
controllers. 

Client workstations communicate with gateways 
over a LAN (token ring, Ethernet, ARCnet, token 
bus) using one of the many NetBIOS LAN 
protocols, Novell’s IPX/SPX, or TCP/IP. 

Most client workstations support the expected 3174 
LU types (LU 1, LU 2 and LU 3). Some also 
support LU 0 and/or LU 6.2 (for APPC). The 
addition of these two LU types changes the gateway 
and client designation from 3270 to SNA. Some 
gateways support PU Type 2.1, necessary for host- 
independent LU 6.2-to-LU 6.2 communication. 


Getting to the Host 

The following eight types of host connections from 
SNA gateways are possible today: 

1. SDLC link, over switched or permanent 
circuits, with a V.24/V.28 (EIA-232-D), 
V.35, or X.21 interface 

2. X.25 link, using qualified logical link 
control (QLLC), with V.24/V.28 (EIA- 
232-D), V.35, or X.21 interface 

3. Token ring, via a 3745 adapter, ES/9370 
adapter, 3172 interconnect controller, or 
3174-based token ring gateway 

4. DFT-mode coaxial cable or IBM 
Cabling System, with a five-session 
limitation, via an IBM 3174, 3274, or 
equivalent 

5. Multiplexed DFT-mode coaxial cable or 
IBM Cabling System, with a 40-session 
limitation, via an IBM 3174, 3274, or 
equivalent (appearing as an IBM 3299 
Model 2 or 3) 

6. Multiplexed DFT-mode coaxial cable, 

IBM Cabling System, or fiber-optic 
cable, with a 160-session limitation, via 
an IBM 3174 (appearing as an IBM 
3299 Model 032) 

7. Ethernet, via a 3172 or McDATA 7100 
controller 

8. Host channel, either bus-and-tag or 
ESCON 

Most gateway vendors have products that provide 
host connectivity options 1, 3, and 4, although the 
fourth option is obviously quite limited in capacity. 
Some (including Attachmate and NSA) support 
SDLC adapters with built-in synchronous modems. 

A number of vendors also offer option 2, mainly for 
the European market. There is also a very strong 
demand for an X.21 interface for both switched and 
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nonswitched operation. Several vendors (including 
Eicon, Novell, and NSA) support V.35 adapters, 
which avoids the need for a V.28/V.35 converter for 
56- and 64-kbit/s operation. 

Rabbit Software’s RabbitGATE II and Data Interface’s 
DI3270 LAN Gateway also support option 5, as does 
Novell with its older NetWare SNA Gateway. 

McDATA’s 7100 can provide option 7, Ethernet host 
connectivity to gateways, by providing an Ethernet 
interface that looks like a token ring to the host. 
(McDATA has tested it with Attachmate and NSA 
gateways so far.) IBM’s OS/2 EE supports SNA 
over Ethernet natively, using the connection 
provided by the 3172 with the Interconnect 
Enhancement feature and VTAM V3R4. 

So far, no gateway vendors offer either options 6 or 
8, although option 6 is an elementary extension of 
option 5. With a data rate of 2.35 Mbit/s, the 
Category A interface is usually adequate for the 
support of 160 sessions. Token ring alternatives 
make it unlikely that we shall see any gateways 
offering this option. 

Channel adapters for PCs, including PS/2s, already 
exist. It is only a matter of time before the major 
SNA gateway vendors offer channel-attachment 
support, possibly including support for attachment to 
the ESCON channel director. 

SNA Client-to-Gateway Connections 

At its most basic, the client-to-gateway LAN 
connection operates as a replacement for the 
terminal-to-controller coaxial connection. However, 
given the flexibility of LAN connections and the 
multisession capabilities of today’s SNA client 
workstations, the available connection options are 
anything but basic. 

Whereas a multisession distributed function terminal 
(DPT), such as the IBM 3472-G, can be coaxially 
connected only to a single controller, a multisession 
SNA client workstation can, if necessary, use a 
different gateway for every session (and gateway 
selection can, moreover, be dynamic). Whereas a 
3270 terminal may only be 1500 meters (about 5000 


feet) from the controller, wide area LAN interconn¬ 
ection (via bridges or routers) allows SNA client 
workstations to be any distance from the gateway. 

Although establishment controllers can provide 
access to up to eight hosts per data link, they do not 
offer the path redundancy for their locally attached 
devices that is available with two or more SNA 
gateways. When the controllers are acting as a token 
ring (or, in McDATA’s case, Ethernet) gateway, their 
downstream PC-based clients do not have this 
limitation because they can connect to any gateway 
on the LAN. 

SNA Client Workstation 
Characteristics 

Gateway vendors have implemented SNA client 
workstation software in two different ways: (1) a 
split stack—LU or partial LU on the client work¬ 
station with a single PU on the gateway or (2) a full 
stack—PU and LU on each client workstation. 
Having a full SNA stack gives each client work¬ 
station the greatest connectivity flexibility. The 
disadvantage is increased memory use which can be 
a problem for DOS workstations. Memory use is 
less critical in Windows or OS/2 environments and 
vendors using the full stack approach (IBM, 
Attachmate) have made efforts to minimize memory 
usage. In both direct client-to-host communication 
over a LAN and peer to peer communication, the full 
stack has an advantage over split stack, providing 
direct communication instead of triangulated via the 
gateway (see figures 5 and 6 on page 13). 

LU Type 2 

Client workstation capabilities vary from one vendor 
to another. 

Most DOS-based workstations provide crisp text¬ 
mode emulation of the four most popular screen 
formats (24x80, 32x80,43x80, and 27x132, often 
referred to as Models 2 through 5) and take advan¬ 
tage of VGA or super VGA characteristics to display 
the three larger formats without the need for scrolling. 
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Treatment of the operator information area (OIA), or 
status line, reflects a variety of philosophies. Some 
vendors have taken the trouble to faithfully 
reproduce the special symbols used by the 
nonprogrammable terminals; others have abandoned 
the effort. Extra information, displayed 
continuously or invoked by keystroke, includes 
server name, local address, LAN connection 
messages, row and column number, etc. 

Several vendors (Attachmate, DCA, IBM, Novell, 
and Rabbit) support the small maiket for APL 
(A Programming Language). All but IBM and 
Novell provide APL only as part of an extra-cost 
graphics package. 

Most vendors now offer or are developing Windows- 
based workstations. IBM’s Personal Communica¬ 
tions/3270 can be customized for DOS or Windows. 
New functions are possible in a Windows 
environment and these are in great demand. 

Features such as cut-and-paste and dynamic data 
exchange (DDE) for passing data between the 3270 
emulation software and other Windows applications 
are much sought after. 

Support of multiple national languages is important 
for those vendors who do not wish to limit their sales 
to the U.S. IBM’s support includes other alphabets, 
such as Greek and Cyrillic. Adoption of IBM’s code 
page approach is now regarded as essential for 
display, keyboard, and printer support. 



Figure 5 


LU Type 1 and 3 

Most 3270 client workstations can be configured to 
support one or more host-addressable printers, often 
with the option to redirect print requests to the LAN 
printer spool queue. 

Given that host-addressable printers are not 
generally considered to be in a user’s private 
domain, it is reasonable to allow the attachment of 
printers to the SNA gateway (directly or via the 
LAN spool queue). However, at the moment, printer 
data streams must be routed to a workstation for 
capture back to the LAN spool queue. Doubtless, 
gateway vendors are working on ways to eliminate 
this wasteful process, perhaps by incorporating 
printer LUs directly into the gateway software. 

LU Type 6.2 

The appearance of APPC applications has been slow. 
However, many large end users increasingly see 
APPC capability as a necessity and are developing 
applications to exploit it. Most gateway vendors 
have yet to introduce APPC support. 

Most gateway vendors view IBM OS/2 Extended 
Edition (EE) as their standalone competition and 
have or are developing APPC support that is OS/2 
EE-compatible rather than APPC/PC-compatible. 
This OS/2 EE-compatible support is not just for 
OS/2 clients but is also for DOS and Windows 
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clients. It is becoming known as APPC/EE. IBM 
OS/2 2.0 does not have an Extended Edition with 
modules such as Communication Manager and 
Database Manager bundled in. Instead, these 
modules are available separately as Extended 
Services (ES), and APPC support will be provided 
by the Communication Manager ES. The level of 
APPC support will be equivalent to that provided by 
Network Services/2 including the CPI-C interface. 
Novell is one of the few exceptions, developing 
support that is APPC/PC compatible. 

File Transfer 

The host file transfer utility IND$FILE and the send 
and receive components of the 3270 emulation allow 
files to be transferred between the host and the 
client’s local disk. This and the High-Level 
Language Application Programming Interface 
(HLLAPI) feature are available irrespective of 
whether the PC is attached to a 3174 or attached to 
an SNA gateway. 

HLLAPI 

HLLAPI and EHLLAPI applications interface to the 
LU via HLLAPI, bypassing the regular 3270 screen. 
HLLAPI provides a customizable graphical interface 
to the user. Another benefit of using HLLAPI 
applications is that they can be easily modified to 
manage changes in contrast to the considerable 
effort of modifying the host application. 

Asynchronous Dial-In Support 

A few vendors (Attachmate, Novell) provide 
asynchronous dial-in support for remote non- 
LAN-attached 3270 clients, either on the gateway 
itself or via a LAN-attached communications server. 
The advantage asynchronous dial-in to a gateway 
has over synchronous (SDLC) dial-in direct to the 
SNA network is that, in most cases, a gateway site is 
closer to the remote client than a site with a 
communication controller (37x5). The telephone 
toll charges are therefore less. Also, providing dial- 
in ports on a communication controller is much more 
expensive than providing ports for access to a 
gateway. 


3174 Capabilities Not Yet In 
SNA Gateways 

The following capabilities are not all equally 
desirable. However, most of them will probably be 
available on various SNA gateways in the next year 
or so. 

• DSPU support via LAN or ISDN connection 

• Printer authorization matrix (PAM) 

• Between brackets printer sharing 

• Intelligent printer data stream (IPDS) support 

• Local format storage 

• NetView support 

• Response-time monitor 

• APPN 

DSPU support via LAN or ISDN connection 

Some gateways, including IBM’s, treat their client 
workstations as downstream physical units (DSPUs). 
Most do not. Full DSPU support would likely 
permit the use of downstream SNA gateways. 

Printer authorization matrix 

On a 3174, the PAM is used to associate display 
terminals with the printers or printer classes on 
which they are permitted to perform local-copy 
printing. Selection of a printer class allows display 
users to print on the first available printer that 
satisfies their needs. IBM documentation offers the 
simple example of “any printer with yellow paper.” 

A PAM may be specified at 3174 customization time 
or may be downloaded from the host. In addition to 
printer [classj/display relationships, it includes 
specification of printer type—i.e., host only, shared, 
and local only. 

When an SNA gateway is coaxially attached to a 
3174, its client workstations may direct local-copy 
printing to 3174-attached printers under the control 
of the PAM. For other than a coaxial attachment or, 
in any case, for LAN or workstation-attached 
printers, the absence of PAM support might cause 
problems for some installations. Most gateways do. 


14 


February , 1992 




SNA Perspective 


©CSI 


of course, provide for local-copy printing, but SNA 
Perspective has not identified any that are PAM- 
compatible. 

Between Brackets Printer Sharing 

Only a few gateways already provide between 
brackets printer sharing. On a 3174, this capability 
applies to printers that are defined as shared. Host 
printer data streams are batched as work units, each 
of which corresponds, for example, to a user- 
requested report. Each work unit is defined as a 
bracket and is delineated by beginning and ending 
bracket indicators. Local-copy printing is permitted 
between brackets. 

Although today’s low-cost printers have eliminated 
most of the economic arguments for host/local 
printer sharing, it continues to be a requirement in 
some installations. 

Intelligent Printer Data Stream Support 

Graphics and font selection, sizing, orientation, and 
positioning are commonplace on printers, especially 
laser printers, used in conjunction with word 
processing, desktop publishing, and graphics 
applications on personal computers. IPDS offers the 
same capability for host-originated data streams. It 
is a safe bet that the leading vendors of SNA 
gateways and client workstations will offer this 
capability within the next year. 

Local Format Storage 

Actual 3174s provide this only for control unit 
terminals (CUTs). This is, however, a local 
restriction and is transparent to CICS, which is the 
host application subsystem with which local format 
storage is most commonly used. With the actual 
3174, formats must be downloaded after the 
controller is IMLed (initial microprogram loaded). 
However, a gateway could be designed to save the 
formats to disk for subsequent reloading. 

NetView Support 

The 3174 can be configured as a NetView Entry 
Point, supporting the monitoring of events and 
alerts, the tracking of asset information (including 
Vital Product Data and Extended Vital Product 
Data), and the downloading of microcode (central 
site change management). The number of SNA 


gateway vendors offering NetView Entry Point 
support is increasing and includes CSI, DCA (OS/2 
products only), Novell, and Rabbit Software. 

Response-Time Monitor 

This tool, which requires code in both the gateway 
and the client workstations, is important to SNA 
network administrators. It is the means by which 
they identify degraded performance and thus plan 
upgrade and configuration strategies. Most vendors 
are expected to offer this as a component of their 
NetView support. 

APPN 

In March 1991, IBM added both advanced peer-to- 
peer networking (APPN) end node and network 
node functionality to the 3174. This allows the 3174 
to be a full APPN routing node, providing support 
for peer topologies and support for client/server 
applications. In January, though, IBM announced 
that it will license APPN network node, so gateways 
in the future may include this capability. 

The Future of the 3174 
and Gateways 

When there is a requirement for nonprogrammable 
terminals, it is hard to beat the 3174 and its direct 
competitors. Moreover, there is still nothing like a 
channel-attached controller for sheer performance. 

There is no doubt that market for nonprogrammable 
terminals is quickly shrinking. With it goes the need 
for the initial primary function of establishment 
controllers, even though they can also provide 
gateway functions for LAN-attached PCs. IBM has 
addressed the need for a low cost, limited 
connectivity, remote token ring LAN gateway with 
the 3174 model 90R Token Way controller. But as a 
hardware architecture, it cannot compete well with 
the flexibility, openness, and rapid development of 
software gateways. The addition of the important 
remaining 3174 capabilities to these gateways is 
only a matter of time. Faster LANs coupled with 
faster server and workstation hardware should soon 
eliminate the performance advantage of the 
specialized controller. 
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SNA Perspective speculates that, although IBM will 
continue to enhance the 3174, there will be no direct 
follow-on product to it. IBM will undoubtedly 
continue to market the 3174 for many years while 
there is still demand. 

Some of the unique 3174 functionality, such as coax 
terminal support, may be added into a future 
RS/6000-based product in a communications family 
started by the new 6611 multiprotocol router. IBM 
may also add coax terminal support capabilities to 
the 3172 to replace channel-attached 3174s. This 
would certainly provide sufficient coax support for 
the operator terminals in the computer room. The 
3172 already provides the token ring LAN 
connectivity available with the 3174. However, the 
addition of coax support seems less likely to us, 
since IBM seems to prefer the 3172 to operate as 
only a LAN-level interconnect. 

It would be a considerable effort for IBM to port 
some or all of the 3174 microcode from its 
proprietary processor to either the Intel 
microprocessor of the 3172 or the RISC processor of 
the RS/6000. However, this may prove more 
effective in the long run than continually coding new 
advances for both IBM’s 3174 and gateway 
products. If 3174 microcode were ported to the 
3172, then it would be a short stretch for any PC or 
communication server with an Intel microprocessor 
with the appropriate coax or asynchronous cards to 
then function like a 3174. That might be worth the 
effort. However, since the 3174 is a reliable 
technology and can serve users well into this decade, 
it is unclear when IBM will decide that an alternate 
solution is necessary. 

What does the future hold for the SNA gateway? 
Besides filling in the remaining pieces of missing 
3174 functionality described above, we can look 
forward to many new features and enhancements. 
SNA Perspective expects to see increased 
manageability by industry-standard network 
managers, APPN end node—and perhaps even 
licensed network node—support, and more support 
of native Ethernet SNA host connections. And we 
expect, in the not-too-distant future, 3270 over LU 
6.2 on gateways. ■ 


More PCs than 3270 Terminals 
Attached to Controllers 

Shipments 

During 1990, for the first time, more personal compu¬ 
ters became attached to 3270 controller ports than 
3270 terminals, according to Dataquest, a San Jose, 
California market research firm (see Table below). 
The table is based on shipment numbers in the 
United States, which totalled about 1.3 million. 

Devices Attached to 3174-type Controllers 
1990 Shipments — United States 


Displays and Printers Type of Device 

Displays Only 

36% 

PCs 

45% 

35% 

3270 displays 

44% 

4% 

LANs 

5% 

5% 

Other (workstation, midrange) 6% 

1% 

Protocol converter (ASCII) 

2% 

20% 

Printers 


100% 


100% 

1,300,000 

Shipments in units 

1,050,000 


Note: Columns may not add to totals due to rounding. 

Source: Dataquest 

The percentage of PCs that appear to host 
applications as 3270 devices is actually even higher 
than these numbers indicate, for several reasons. 

The LAN number in the table counts the number of 
LANs rather than the number of devices that access 
the controller across those LANs. Further, these 
numbers include only devices on controller ports; they 
do not include devices which access applications 
other than through controller ports, such as PCs 
connected directly or LANs with SNA gateways 
connecting through 3745 communication controllers 
or 3172 LAN interconnect controllers. 

This crossover between PCs and terminals happened 
in the same year, 1990, in which U.S. shipments of 
3270 terminals dropped by an unprecedented 30 
percent. Dataquest’s preliminary 1991 figures also 
show a drop, though not as dramatic, in 3270 terminal 
shipments. 

Installed Base 

Dataquest also expects that during 1992 PCs will also 
outnumber 3270 terminals in the installed base of 
devices attached to controllers. At the end of 1990, 
just 50 percent of the installed base of eight million 
3270-appearing devices on controllers were actually 
3270 terminals from IBM or vendors of compatible 
products. ■ 
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IBM Announcements 


Router and New 
SNMP for RS/6000 
Unveiled 

On January 21, IBM made several strategic 
announcements related to multiprotocol network 
routing and distributed network management. 

6611 Router 

IBM’s long-awaited multiprotocol bridge-router, the 
6611, is based, as expected, on the RS/6000 
architecture. Its functionality is analyzed in this 
month’s Architect’s Corner. The four-slot model 140 
base price is $9,995 while the seven-slot model 170 
has a base price of $18,640. Both models are 
scheduled to ship in June. 

AIX NetView/6000 

AIX NetView/6000 provides network management 
for the new router as well as for TCP/IP devices with 
SNMP agents. These are found extensively in 
environments such as UNIX and LANs. It also 
monitors all IP addressable devices. 

Significant features include its OSF/Motif-based 
graphical user interface, a dynamic network 
discovery and mapping capability, and SNMP fault, 
performance, and configuration management 
features. AIX NetView/6000 replaces AIX Network 
Manager/6000. 

Used with AIX NetView Service Point, it provides 
what IBM temis cooperative network management 
with NetView. Traps from SNMP agents are filtered 
and converted to SNA alerts by AIX NetView/6000 


and then sent to NetView via AIX NetView Service 
Point. AIX NetView/6000 can accept commands 
from NetView and respond back. 

This cooperative management is consistent with 
IBM’s System View strategy. As OSF’s DME 
technology is delivered, AIX NetView/6000 will be 
DME conformant. 

IBM is working with other vendors so that their 
products can be managed by AIX NetView/6000, by 
supporting their SNMP MIBs. These MIBs will be 
shipped to users with AIX NetView/6000. 
Companies already participating in this Networking 
Services Vendor Enablement Program include 
Chipcom, Fibermux, Hewlett-Packard, Optical Data 
Systems, Network Equipment Technologies, 

Proteon, SynOptics Communications, Wellfleet, 
Xylogics, and Xyplex. 

Slated for June availability, the AIX NetView/6000 
is composed of two parts. The SNMP Manager 
license fee is $9,950 and the End User Interface 
license fee is $4,950. 

Licensing APPN Network Node 

In its press release on the 6611 and AIX 
NetView/6000, IBM included the following 
sentence: “IBM intends to license APPN network 
node support for use by other manufacturers.” 

When asked, IBM stated that no further information 
is currently available. This statement of intention 
(not an official Statement of Direction) was meant to 
express officially what IBM sources have been 
openly discussing with users, consultants, and the 
press for several months. 

SNA Perspective believes that IBM has not 
completed its project planning for developing a 
source code product nor has the company completed 
its pricing and marketing structure for it. Because of 
the importance of APPN (see SNA Perspective 
January 1992), we believe both this issues are 
receiving attention at the highest levels within IBM’s 
Networking Systems line of business. ■ 
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Baby Steps—SNA 
and Multiprotocol 
Routing 


by Dr. John R. Pickens 

Dateline 21 January 1992 

"IBM expands its network software 
offerings by introducing the IBM 
Multiprotocol Network Program (5648- 
016), IBM's first multiprotocol, 
multiport, bridge and router 
software product supporting the new 
IBM 6611..." IBM programming 
announcement 292-017. 

"IBM intends to license Advanced 
Peer-to-Peer Networking (APPN) 
network node support for use by 
other manufacturers." IBM press 
release. 

"[Network Equipment Technologies 
(N.E.T.) and IBM announce] an 
agreement to license IBM's new Data 
Link Switching technology to N.E.T." 
N.E.T. press release. 

In last month’s Architect's Comer, I outlined a four- 
quadrant model for standards—proprietary/public- 
domain development on one axis by open/closed 
availability on the other axis. I ended the discussion 
with the rhetorical question “In which quadrant will 
SNA APPN routing emerge?” The wait was 
surprisingly short. The answer—proprietary-open. 
Even more interesting was the announcement of 
another architecture—data link switching. 

In this month’s column. I’ll consider three questions 
raised by this announcement: How complete is IBM’s 
multiprotocol routing? What will be the impact of 
open APPN routing? What is data link switching? 


IBM’s Multiprotocol Bridge/Router 

Table 2 summarizes the protocol and feature content 
of IBM’s initial router software release for the 6611 
as described in the product announcement. For each 
routable protocol, both the end system and 
intermediate system connectivity options are shown. 
Connectivity for each type of bridging paradigm 
(source route bridging, transparent bridging, and 
source route transparent) is also shown. The 
mapping of SNA data link and NetBIOS/LLC2 to 
TCP is also shown. 


IBM Router Support Matrix 
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► Supported 


O Not supported - Not applicable 


DLS = Data Link Switching SR = Source Route 
EN = End Node T = Transparent 

ES = End System SRT = Source Route Transparent 

PPP = Point-to-Point Protocol SRTB = 8290-type Bridge 
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On the whole, the router feature content is a solid 
first step. With routable support for IP, XNS, IPX, 
DECnet, and AppleTalk, plus support for source 
route bridging, the product makes a respectable entry 
into this market. But significant holes exist—some 
expected, some not. 

• No SNA routing (tunnels but no routes). As 
IBM has been discussing since last fall, the 
company chose to enter the multiprotocol router 
market with a product that does not route SNA. 
Rather, IBM tunnels SDLC and LLC2—the two 
primary data links for SNA—across TCP 
sessions. At least a clear direction is given that 
when SNA routing capability is offered, it will 
be based upon APPN network node (not subarea 
PU 4). I’d expect a new release of 6611 
software which will include APPN network 
node sometime before mid-1993. 

• Limited Ethemet/802.3 support. No generalized 
bridging for Ethernet end systems and no SNA 
data link switching services for Ethernet end 
systems. Given IBM’s push in recent years 
toward accommodation of Ethernet (and other 
IEEE 802 standards) within IBM networks, this is 
surprising. 

• Weak SNMP MIB support. Two SNMP MIBs 
were announced—MIB II and an IBM- 
proprietary MIB. But MIBs exist for many other 
functions—bridging, OSPF, DECnet, AppleTalk, 
token ring interface, Ethernet interface, point-to- 
point protocool (PPP), etc. Implementation of 
these MIBs is lacking. 

• Weak X.25 support. Only the IP routing 
function is supported on X.25. 


• Weak bridging function. Only token ring source 
routing is supported. Other than Ethemet-to- 
Token-ring translation bridging it la 8209, no 
support exists for Ethernet. No support for 
transparent bridging (IEEE 802.ID) nor the 
more recent source route transparent (SRT) 
extensions. These limitations restrict the 
applicability of the product’s bridging function 
to existing token ring environments only. As a 
general mixed media bridge (IEEE 802 LAN, 
FDDI, etc.), the announced bridge function is 
sorely lacking. 

Open APPN 

A year ago, I predicted in this column that APPN 
network node would remain closed. Unfortunately, I 
made no caveat about the price of openness (i.e., 
license fee). Well, on this one, I have to eat my 
words. APPN is open. 

(Editor's Note: We will be cooking up a banquet for our 
architect, with the main course to be that issue of SNA 
Perspective, sliced in strips and sauteed in a white wine sauce.) 

I have a feeling that IBM will see significant interest 
in APPN network node licensing by communications 
and router vendors. This is a big step. 

Data Link Switching 

Data link switching is a tunneling architecture (see 
Figure 7). SDLC, LLC2, and NetBIOS are currently 
included. (Look for QLLC/X.25 in the future.) Data 
link switching basically fulfills one function—to 
enable transport of SDLC, LLC2, and NetBIOS/ 
LLC2 traffic across IP internets using IP routing. 
Local termination of LLC2 and SDLC connections 
is necessary in this scheme because of the increased 
latency seen in IP routing environments. Local 
termination, which is not shown explicitly in the 
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figure, internally terminates the 802.2 layer and 
locally acknowledges frames—handles the polling 
for SDLC and the “keep alive” for LLC2. 

This keeps the connection timers from expiring. 
Note, however, that while data link switching can 
convert SDLC on one end of the tunnel to LLC2 on 
the other and vice versa, it can only connect 
NetBIOS traffic on one end to NetBIOS on the other. 
Further details are unavailable at present 

N.E.T.’s agreement to license data link switching 
from IBM hints that data link switching, like APPN, 
will be an open, proprietary architecture. I expect 
IBM to open data link switching. If this does occur, 
it will be in the context of other router vendors’ 
tunneling schemes, which are not only proprietary 
but closed. It will be interesting to see whether, 
because of IBM’s data link switching, these other 


vendors choose to open their schemes (“I’d rather 
fight than switch”) or accept IBM’s scheme as a 
de facto standard. The coming months will be interes¬ 
ting from the perspective of multivendor politics. 


Conclusion 

IBM’s multiprotocol router, open APPN, and data 
link switching services are now on the playing field. 
Despite holes, weaknesses, and questions about 
detail, these moves represent credible steps and will 
ultimately benefit users, both by encouraging 
multiyendor interoperability and by further 
justifying the needs and advantages of multiprotocol 
routing. By opening APPN network node, IBM has 
taken a big step toward eliminating the confusion 
between APPN and subarea SNA routing. Baby 
steps and big steps. ■ 
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